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Abstract 


Electronic signatures have a limited lifespan with respect to the time period that they can be 
validated and determined to be authentic. The Signature Validation Token (SVT) defined in this 
specification provides evidence that asserts the validity of an electronic signature. The SVT is 
provided by a trusted authority, which asserts that a particular signature was successfully 
validated according to defined procedures at a certain time. Any future validation of that 
electronic signature can be satisfied by validating the SVT without any need to also validate the 
original electronic signature or the associated digital certificates. The SVT supports electronic 
signatures in Cryptographic Message Syntax (CMS), XML, PDF, and JSON documents. 
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This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor 
has chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9321. 
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1. Introduction 


Electronic signatures have a limited lifespan regarding when they can be validated and 


October 2022 


determined to be authentic. Many factors make it more difficult to validate electronic signatures 


over time. For example: 


* Trusted information about the validity of the certificate containing the signer's public key is 


not available. 


* Trusted information about the time when the signature was actually created is not available. 
* Algorithms used to create the electronic signature may no longer be considered secure at the 


time of validation and may therefore no longer be available in software libraries. 


* Services necessary to validate the signature are no longer available at the time of validation. 


* Supporting evidence such as certification authority (CA) certificates, Online Certificate Status 
Protocol (OCSP) responses, Certificate Revocation Lists (CRLs), or timestamps is not available 


or can't be validated. 


The challenges to validation of an electronic signature increase over time, and eventually it may 


simply be impossible to verify the signature with a sufficient level of assurance. 
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Existing standards, such as the ETSI XAdES [XADES] profile for XML signatures [XMLDSIG11], 
ETSI PAdES [PADES] profile for PDF signatures [ISOPDF2], and ETSI CAdES [CADES] profile for 
CMS signatures [RFC5652], can be used to extend the time within which a signature can be 
validated at the cost of significant complexity, which involves storing and validating significant 
amounts of external evidence data such as revocation data, signature time stamps, and archival 
time stamps. 


The Signature Validation Token (SVT) defined in this specification takes a trusted signature 
validation process as an input and preserves the validation result for the associated signature 
and signed document. The SVT asserts that a particular electronic signature was successfully 
validated by a trusted authority according to defined procedures at a certain time. Those 
procedures MUST include checks that the signature match the signed document, checks that the 
signature can be validated by the signing certificate, and checks that the signing certificate pass 
certificate path validation [RFC5280]. Those procedures MAY also include checks associated with 
a particular trust policy such as that an acceptable certificate policy [RFC5280] [RFC3647] was 
used to issue the signer's certificate and checks that an acceptable signature policy was used by 
the signer [RFC3125]. 


Once the SVT is issued by a trusted authority, any future validation of that electronic signature 
can be satisfied by validating the SVT without any need to also revalidate the original electronic 
signature. 


As the SVT is used to preserve validation results obtained through applying existing standards 
for signature validation, it is complementary to and not a replacement for such standards, 
including the ETSI standards for long-term validation listed above. The SVT does, however, have 
the potentially positive effect that it may significantly reduce the need to apply complex long- 
term validation and preservation techniques for signature validation if an SVT is issued and 
applied to the signed document at an early stage where the signature can be validated without 
support of large amounts of external evidence. The use of SVTs may therefore drastically reduce 
the complexity of revalidation of old archived electronic signatures. 


The SVT can be signed with private keys and algorithms that provide confidence for a 
considerable time period. In fact, multiple SVTs can be used to offer greater assurance. For 
example, one SVT could be produced with a large RSA private key, a second one with a strong 
elliptic curve, and a third one with a quantum safe digital signature algorithm to protect against 
advances in computing power and cryptanalytic capabilities. Further, the trusted authority can 
add additional SVTs in the future using fresh private keys and signatures to extend the lifetime of 
the SVTs if necessary. 


2. Definitions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


This document use the following terms: 
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Signed Data: The data covered by a particular electronic signature. This is typically equivalent 
to the signed content of a document, and it represents the data that the signer intended to 
sign. In some cases, such as in some XML signatures, the Signed Data can be the collection of 
several data fragments each referenced by the signature. In the case of PDF, this is the data 
covered by the "ByteRange" parameter in the signature dictionary. In JSON Web Signature 
(JWS), this is the unencoded payload data (before base64url encoding). 


Signed Bytes: These are the actual bytes of data that were hashed and signed by the digital 
signature algorithm. In most cases, this is not the actual Signed Data but a collection of 
signature metadata that includes references (hash) of the Signed Data as well as information 
about algorithms and other data bound to a signature. In XML, this is the canonicalized 
SignedInfo element. In CMS and PDF signatures, this is the DER-encoded SignedAttributes 
structure. In JWS, this is the protected header and payload data formatted according to 
[RFC7515]. 


When these terms are used as defined in this section, they appear with a capitalized first letter. 


3. Signature Validation Token 


3.1. Signature Validation Token Function 


The Signature Validation Token (SVT) is created by a trusted service to assert evidence of 
successful electronic signature validation using a well-defined and trustworthy signature 
validation process. The SVT binds the validation result to the validated signature, the document 
signed by the signature, and the certificate of the signer. This allows a relying party to verify the 
validity of a signed document without having to revalidate the original signature or to reuse any 
of its associated cryptographic algorithms for as long as the SVT itself can be validated. The SVT 
achieves this by binding the following information to a specific electronic signature: 


e A unique identification of the electronic signature. 

* The data and metadata signed by the electronic signature. 

* The signer's certificate that was validated as part of electronic signature verification. 
* The certification path that was used to validate the signer's certificate. 


* An assertion providing evidence of signature verification, the time the verification was 
performed, the procedures used to verify the electronic signature, and the outcome of the 
verification. 


* An assertion providing evidence of the time at which the signature is known to have existed, 
the procedures used to validate the time of existence, and the outcome of the validation. 


The SVT aims to support long-term validation that can be further extended into the future by 
applying the following strategies: 


* by using secure algorithms with long life expectancy when signing the SVT 
* by reissuing the SVT before it becomes insecure or is considered expired 


Santesson & Housley Informational Page 6 


RFC 9321 Signature Validation Token October 2022 


* optionally, by issuing multiple SVTs with different algorithms to provide redundancy in case 
one algorithm is broken 


3.2. Signature Validation Token Syntax 
The SVT is carried in a JSON Web Token (JWT) as defined in [RFC7519]. 


3.2.1. Data Types 


The contents of claims in an SVT are specified using the following data types: 


String: JSON Data Type of string that contains an arbitrary case-sensitive string value. 


Base64Binary: JSON Data Type of string that contains a Base64-encoded byte array of binary 
data. 


StringOrURI: JSON Data Type of string that contains an arbitrary string or a URI as defined in 
[RFC7519]. It is REQUIRED to contain the colon character (":") to be a URI. 


URI: JSON Data Type of string that contains a URI as defined in [RFC7519]. 
Integer: JSON Data Type of number that contains a 32-bit signed integer value (from -2?! to 
231.1), 
Long: ; Ore ; .963 63. 
JSON Data Type of number that contains a 64-bit signed integer value (from -2^" to 2°°-1). 


NumericDate: JSON Data Type of number that contains data as defined in [RFC7519], which is 
the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 
ignoring leap seconds. 


Boolean: JSON Data Type of boolean that contains the explicit value of true or false. 


Object<Class>: A JSON object holding a claims object of a class defined in this specification (see 
Section 3.2.2). 


Map<Type>: A JSON object with name-value pairs where the value is an object of the specified 
Type in the notation. For example, Map<String> is a JSON object with name-value pairs where 
all values are of type String. 


Array: AJSON array of a specific data type as defined in this section. An array is expressed in 
this specification by square brackets. For example, [String] indicates an array of String values, 
and [Object<DocHash>] indicates an array of DocHash objects. 


Null: AJSON null that represents an absent value. A claim with a null value is equivalent with 
an absent claim. 


3.2.2. Signature Validation Token JWT Claims 
The SVT MUST contain only JWT claims in the following list: 
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"jti": A String data type that is a "JWT ID" registered claim according to [RFC7519]. It is 
RECOMMENDED that the identifier holds a hexadecimal string representation of a 128-bit 
unsigned integer. An SVT MUST contain one "JWT ID" claim. 


iss": A StringOrURI data type that is an "Issuer" registered claim according to [RFC7519], which 
is an arbitrary unique identifier of the SVT issuer. This value SHOULD have the value of a URI 
based on a domain owned by the issuer. An SVT MUST contain one "Issuer" claim. 


iat": A NumericDate data type that is an "Issued At" registered claim according to [RFC7519], 
which expresses the time when this SVT was issued. An SVT MUST contain one "Issued At" 
claim. 


"aud": A [StringOrURI] data type or a StringOrURI data type that is an "Audience" registered 
claim according to [RFC7519]. The audience claim is an array of one or more identifiers, 
identifying intended recipients of the SVT. Each identifier MAY identify a single entity, a group 
of entities, or a common policy adopted by a group of entities. If only one value is provided, it 
MAY be provided as a single StringOrURI data type value instead of as an array of values. 
Inclusion of the "Audience" claim in an SVT is OPTIONAL. 


"exp": ANumericDate data type that is an "Expiration Time" registered claim according to 
[RFC7519], which expresses the time when services and responsibilities related to this SVT are 
no longer provided by the SVT issuer. The precise meaning of the expiration time claim is 
defined by local policies. See implementation note below. Inclusion of the "Expiration Time" 
claim in an SVT is OPTIONAL. 


"sig val claims": An Object<SigValidation> data type that contains signature validation claims 
for this SVT extending the standard registered JWT claims above. An SVT MUST contain one 
sig val claims claim. 


Note: An SVT asserts that a particular validation process was undertaken at a stated time. This 
fact never changes and never expires. However, some other aspects of the SVT such as liability 
for false claims or service provision related to a specific SVT may expire after a certain period of 
time, such as a service where an old SVT can be upgraded to a new SVT signed with fresh keys 
and algorithms. 


3.2.3. SigValidation Object Class 


The sig val claims JWT claim uses the SigValidation object class. A SigValidation object holds all 
custom claims, and a SigValidation object contains the following parameters: 


ver": A String data type representing the version. This parameter MUST be present and the 
version in this specification indicated by the value "1.0". 


"profile": A StringOrURI data type representing the name of a profile that defines conventions 
followed for specific claims and any extension points used by the SVT issuer. This parameter 
MUST be present. 
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"hash_algo": A URI data type that identifies the hash algorithm used to compute the hash values 
within the SVT. The URI identifier MUST be one defined in [RFC9231] or in the IANA registry 
defined by this specification. This parameter MUST be present. 


"sig" An [Object<Signature>] data type that gives information about validated electronic 
signatures as an array of Signature objects. If the SVT contains signature validation evidence 
for more than one signature, then each signature is represented by a separate Signature 
object. At least one Signature object MUST be present. 


"ext": A Map<String> data type that provides additional claims related to the SVT. Extension 
claims are added at the discretion of the SVT issuer; however, extension claims MUST follow 
any conventions defined in a profile of this specification (see Section 4). Inclusion of this 


parameter is OPTIONAL. 


3.2.4. Signature Claims Object Class 

The sig parameter in the SigValidation object class uses the Signature object class. The Signature 
object contains claims related to signature validation evidence for one signature, and it contains 
the following parameters: 


"sig ref": An Object<SigReference> data type that contains reference information identifying 
the target signature. This parameter MUST be present. 


"sig data_ref": An [Object<SignedDataReference>] data type that contains an array of 
references to Signed Data that was signed by the target electronic signature. At least one 
SignedDataReference object MUST be present. 


"signer_cert_ref": An Object<CertReference> data type that references the signer's certificate 
and optionally references a supporting certification path that was used to verify the target 
electronic signature. This parameter MUST be present. 


"sig val": An [Object<PolicyValidation>] data type that contains an array of results of signature 
verification according to defined procedures. At least one PolicyValidation object MUST be 


present. 


"time_val": An [Object<TimeValidation>] data type that contains an array of time verification 
results showing that the target signature has existed at a specific time in the past. Inclusion of 
this parameter is OPTIONAL. 


"ext": A MAP<String> data type that provides additional claims related to the target signature. 
Extension claims are added at the discretion of the SVT issuer; however, extension claims 
MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion 


of this parameter is OPTIONAL. 


3.2.5. SigReference Claims Object Class 


The sig_ref parameter in the Signature object class uses the SigReference object class. The 
SigReference object provides information used to match the Signature claims object to a specific 
target electronic signature and to verify the integrity of the target signature value and Signed 
Bytes, and it contains the following parameters: 
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"id": A String data type that contains an identifier assigned to the target signature. Inclusion of 
this parameter is OPTIONAL. 


"sig hash": A Base64Binary data type that contains a hash value of the target electronic 
signature value. This parameter MUST be present. 


"sb_hash": A Base64Binary data type that contains a hash value of the Signed Bytes of the target 
electronic signature. This parameter MUST be present. 


3.2.6. SignedDataReference Claims Object Class 


The sig_data_ref parameter in the Signature object class uses the SignedDataReference object 
class. The SignedDataReference object provides information used to verify the target electronic 
signature references to Signed Data as well as to verify the integrity of all data that is signed by 
the target signature, and it contains the following parameters: 


"ref": A String data type that contains a reference identifier for the data or data fragment 
covered by the target electronic signature. This parameter MUST be present. 


"hash": A Base64Binary data type that contains the hash value for the data covered by the target 
electronic signature. This parameter MUST be present. 


3.2.7. PolicyValidation Claims Object Class 


The sig_val parameter in the Signature object class uses the PolicyValidation object class. The 
PolicyValidation object provides information about the result of a validation process according to 
a specific policy, and it contains the following parameters: 


"pol": A StringOrURI data type that contains the identifier of the policy governing the electronic 
signature verification process. This parameter MUST be present. 


"res": A String data type that contains the result of the electronic signature verification process. 
The value MUST be one of "PASSED", "FAILED", or "INDETERMINATE" as defined by 
[ETSI319102-1]. This parameter MUST be present. 


"msg": A String data type that contains a message describing the result. Inclusion of this 
parameter is OPTIONAL. 


ext": A MAP<String> data type that provides additional claims related to the target signature. 
Extension claims are added at the discretion of the SVT issuer; however, extension claims 
MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion 
of this parameter is OPTIONAL. 


3.2.8. TimeValidation Claims Object Class 


The time_val parameter in the Signature object class uses the TimeValidation object class. The 
TimeValidation claims object provides information about the result of validating evidence of 
time asserting that the target signature existed at a particular time in the past. Evidence of time 
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is typically a timestamp according to [RFC3161], but other types of evidence may be used such as 
a previously issued SVT for this signature. The TimeValidation claims object contains the 
following parameters: 


"time": A NumericDate data type that contains the verified time. This parameter MUST be 
present. 


"type": A StringOrURI data type that contains an identifier of the type of evidence of time. This 
parameter MUST be present. 


iss": A StringOrURI data type that contains an identifier of the entity that issued the evidence 
of time. This parameter MUST be present. 


"id": A String data type that contains an unique identifier assigned to the evidence of time. 
Inclusion of this parameter is OPTIONAL. 


"hash": A Base64Binary data type that contains the hash value of the validated evidence of time. 
Inclusion of this parameter is OPTIONAL. 


"val": An [Object<PolicyValidation>] data type that contains an array of results of the time 
evidence validation according to defined validation procedures. Inclusion of this parameter is 
OPTIONAL. 


ext": A MAP<String> data type that provides additional claims related to the target signature. 
Extension claims are added at the discretion of the SVT issuer; however, extension claims 
MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion 
of this parameter is OPTIONAL. 


3.2.9. CertReference Claims Object Class 


The signer_cert_ref parameter in the Signature object class uses the CertReference object class. 
The CertReference object references a single X.509 certificate or a X.509 certification path either 
by providing the certificate data or by providing hash references for certificates that can be 
located in the target electronic signature, and it contains the following parameters: 


"type": A StringOrURI data type that contains an identifier of the type of reference. The type 
identifier MUST be one of the identifiers defined below, an identifier specified by the selected 
profile, or a URI identifier. This parameter MUST be present. 


"ref": A [String] data type that contains an array of string parameters according to conventions 
defined by the type identifier. At least one parameter MUST be present. 


The following type identifiers are defined: 
"chain": The ref contains an array of Base64-encoded X.509 certificates [RFC5280]. The 
certificates MUST be provided in the order starting with the end entity certificate. Any 


following certificate must be able to validate the signature on the previous certificate in the 
array. 
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"chain hash": The ref contains an array of one or more Base64-encoded hash values where 
each hash value is a hash over a X.509 certificate [RFC5280] used to validate the signature. 
The certificates MUST be provided in the order starting with the end entity certificate. Any 
following certificate must be able to validate the signature on the previous certificate in the 
array. This option MUST NOT be used unless all hashed certificates are present in the target 
electronic signature. 


Note: All certificates referenced using the identifiers above are X.509 certificates. Profiles of this 
specification MAY define alternative types of public key containers; however, a major function of 
these referenced certificates is not just to reference the public key but also to provide the subject 
name of the signer. It is therefore important for the full function of an SVT that the referenced 
public key container also provides the means to identify the signer. 


3.2.10. SVT JOSE Header 


The SVT JWT MUST contain the following JSON Object Signing and Encryption (JOSE) header 
parameters in accordance with Section 5 of [RFC7519]: 


"typ": This parameter MUST have the string value "JWT" (upper case). 


"alg": This parameter identifies the algorithm used to sign the SVT JWT. The algorithm identifier 
MUST be specified in [RFC7518] or the IANA "JSON Web Signature and Encryption Algorithms" 
registry [[ANA-JOSE-REG]. The specified signature hash algorithm MUST be identical to the 
hash algorithm specified in the hash algo parameter of the SigValidation object within the 
sig val claims claim. 


The SVT header MUST contain a public key or a reference to a public key used to verify the 
signature on the SVT in accordance with [RFC7515]. Each profile, as discussed in Section 4, MUST 
define the requirements for how the key or key reference is included in the header. 


4. Profiles 


Each signed document and signature type will have to define the precise content and use of 
several claims in the SVT. 


At a minimum, each profile MUST define: 


* The identifier of the profile 

* How to reference the Signed Data content of the signed document 

* How to reference the target electronic signature and the Signed Bytes of the signature 
* How to reference certificates supporting each electronic signature 

* How to include public keys or references to public keys in the SVT 


* Whether each electronic signature is supported by a single SVT, or one SVT may support 
multiple electronic signatures of the same document 
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A profile MAY also define: 


* Explicit information on how to perform signature validation based on an SVT 


* How to attach an SVT to an electronic signature or signed document 


4.1. Defined Profiles 


The following profiles are defined in appendixes of this document: 


Appendix A: XML Signature Profile 


Appendix B: PDF Signature Profile 


Appendix C: JWS Profile 


Other documents MAY define other profiles that MAY complement, amend, or supersede these 
profiles. 


5. 


Signature Verification with an SVT 


Signature verification based on an SVT MUST follow these steps: 


1 


N 


wW 


(op) c1 


oo N 


. Locate all available SVTs available for the signed document that are relevant for the target 


electronic signature. 


. Select the most recent SVT that can be successfully validated and meets the requirement of 


the relying party. 


. Verify the integrity of the signature and the Signed Bytes of the target electronic signature 


using the sig ref claim. 


. Verify that the Signed Data reference in the original electronic signature matches the 


reference values in the sig data ref claim. 


. Verify the integrity of referenced Signed Data using provided hash values in the sig data ref 


claim. 


. Obtain the verified certificates supporting the asserted electronic signature verification 


through the signer cert ref claim. 


. Verify that signature validation policy results satisfy the requirements of the relying party. 
. Verify that verified time results satisfy the context for the use of the signed document. 


After successfully performing these steps, signature validity is established as well as the trusted 
signer certificate binding the identity of the signer to the electronic signature. 


Santesson & Housley Informational Page 13 


RFC 9321 Signature Validation Token October 2022 


6. IANA Considerations 


6.1. Claim Names Registration 


IANA has registered the "sig val claims" claim name in the "JSON Web Token Claims" registry 
established by Section 10.1 of [RFC7519]. 


6.1.1. Registry Contents 


Claim Name: sig val claims 
Claim Description: Signature Validation Token 
Change Controller: IESG 


Specification Document(s): Section 3.2.3 of RFC 9321 


6.2. Header Parameter Names Registration 


IANA has registered the "svt" Header Parameter in the "JSON Web Signature and Encryption 
Header Parameters" registry established by [RFC7515]. 


6.2.1. Registry Contents 


Header Parameter Name: svt 

Header Parameter Description: Signature Validation Token 
Header Parameter Usage Location(s): JWS 

Change Controller: IESG 


Specification Document(s): Appendix C.1.1 of RFC 9321 


7. Security Considerations 


7.1. Level of Reliance 


An SVT allows a signature verifier to still validate the original signature using the original 
signature data and to use the information in the SVT selectively to confirm the validity and 
integrity of the original data, such as confirming the integrity of Signed Data or the validity of the 
signer's certificate, etc. 


Another way to use an SVT is to completely rely on the validation conclusion provided by the SVT 
and to omit revalidation of the original signature value and original certificate status checking 
data. 


This choice is a decision made by the verifier according to its own policy and risk assessment. 
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However, even when relying on the SVT validation conclusion of an SVT, it is vital to still verify 
that the present SVT is correctly associated with the document and signature that is being 
validated by validating the hashed reference data in the SVT of the signature, signing certificate 
chain, Signed Data, and the Signed Bytes. 


7.2. Aging Algorithms 


Even if the SVT provides protection against algorithms becoming weakened or broken over time, 
this protection is only valid for as long as the algorithms used to sign the SVT are still considered 
secure. It is advisable to reissue SVTs in cases where an algorithm protecting the SVT is getting 
close to its end of life. 


One way to increase the resistance of algorithms becoming insecure, is to issue multiple SVTs for 
the same signature with different algorithms and key lengths where one algorithm could still be 
secure even if the corresponding algorithm used in the alternative SVT is broken. 
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Appendix A. XML Signature Profile 


This appendix defines a profile for implementing SVTs with a signed XML document and defines 
the following aspects of SVT usage: 


* How to include reference data related to XML signatures and XML documents in an SVT 
* How to add an SVT token to an XML signature 


XML documents can have any number of signature elements, signing an arbitrary number of 
fragments of XML documents. The actual signature element may be included in the signed XML 
document (enveloped), include the Signed Data (enveloping), or may be separate from the signed 
content (detached). 


To provide a generic solution for any type of XML signature, an SVT is added to each XML 
signature element within the XML signature <ds:Object> element. 


A.1. Notation 


A.1.1. References to XML Elements from XML Schemas 


When referring to elements from the W3C XML Signature namespace (https://www.w3.org/ 
2000/09/xmldsig#), the following syntax is used: 


* <ds:Signature> 


When referring to elements from the ETSI XAdES XML Signature namespace (https://uri.etsi.org/ 
01903/v1.3.2#), the following syntax is used: 


* <xades:CertDigest> 


When referring to elements defined in this specification (http://id.swedenconnect.se/svt/1.0/sig- 
prop/ns), the following syntax is used: 


* <svt:Element> 


A.2. SVT in XML Documents 


When SVTs are provided for XML signatures, then one SVT MUST be provided for each XML 
signature. 


An SVT embedded within the XML signature element MUST be placed in a 
<svt:SignatureValidationToken> element as defined in Appendix A.2.1. 
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A.2.1. SignatureValidationToken Signature Property 


The <svt:SignatureValidationToken> element MUST be placed in a <ds:SignatureProperty> 
element in accordance with [XMLDSIG11]. The «ds:SignatureProperty» element MUST be placed 
inside a «ds:SignatureProperties» element inside a «ds:Object» element inside a <ds:Signature> 
element. 


Note: [XMLDSIG11] requires the Target attribute to be present in <ds:SignatureProperty>, 
referencing the signature targeted by this signature property. If an SVT is added to a signature 
that does not have an Id attribute, implementations SHOULD add an Id attribute to the 
<ds:Signature> element and reference that Id in the Target attribute. This Id attribute and Target 
attribute value matching is required by the [XMLDSIG11] standard, but it is redundant in the 
context of SVT validation as the SVT already contains information that uniquely identifies the 
target signature. Validation applications SHOULD NOT reject an SVT token because of Id and 
Target attribute mismatch and MUST rely on matching against a signature using signed 
information in the SVT itself. 


The <svt:SignatureValidationToken> element is defined by the following XML Schema: 


<?xml version-"1.0" encoding-"UTF-8"?» 

«xs:schema xmlns:xs-"http://www.w3.0rg/2001/XMLSchema" 
elementFormDefault-"qualified" 
targetNamespace-"http://id.swedenconnect.se/svt/1.0/sig-prop/ns" 
xmlns:svt-"http://id.swedenconnect.se/svt/1.0/sig-prop/ns"» 


«xs:element name-"SignatureValidationToken" 
type-"svt:SignatureValidationTokenType" /» 


«xs:complexType name="SignatureValidationTokenType"> 
«xs:simpleContent» 
«xs:extension base="xs:string"> 
«/xs:extension» 
</xs:simpleContent> 
</xs:complexType> 


</xs:schema> 


The SVT token MUST be included as a string representation of the SVT JWT. Note that this is the 
string representation of the JWT without further encoding. The SVT MUST NOT be represented by 
the Base64-encoded bytes of the JWT string. 


Example: 
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«ds:Signature Id="MySignatureld"> 


«ds :O0bject> 
«ds:SignatureProperties» 
«ds:SignatureProperty Target-"ZMySignatureId'» 
<svt :SignatureValidationToken> 
eyJOeXAiOiJKV1QiLCJhb...2aNZ 
</svt:SignatureValidationToken> 
</ds:SignatureProperty> 
</ds:SignatureProperties> 
</ds:Object> 
</ds:Signature> 


A.2.2. Multiple SVTs in an XML Signature 


If a new SVT is stored in a signature that already contains a previously issued SVT, 
implementations can choose either to replace the existing SVT or to store the new SVT in addition 
to the existing SVT. 


If the new SVT is stored in addition to the old SVT, it SHOULD be stored in a new 
<ds:SignatureProperty> element inside the existing <ds:SignatureProperties> element where the 
old SVT is located. 


For interoperability robustness, signature validation applications MUST be able to handle 
signatures where the new SVT is located in a new <ds:Object> element. 


A.3. XML Signature SVT Claims 


A.3.1. XML Profile Identifier 

When this profile is used, the SigValidation object MUST contain a "profile" claim with the value 
"XML". 

A.3.2. XML Signature Reference Data 


The SVT Signature object MUST contain a "sig ref" claim (SigReference object) with the following 
elements: 


"id": The Id-attribute of the XML signature, if present. 
"sig hash": The hash over the signature value bytes. 


"sb_hash": The hash over the canonicalized <ds:SignedInfo> element (the bytes the XML 
signature algorithm has signed to generate the signature value). 
A.3.3. XML Signed Data Reference Data 


The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) 
for each <ds:Reference> element in the <ds:SignedInfo> element. The "sig data" claim MUST 
contain the following elements: 
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"ref": The value of the URI attribute of the corresponding <ds:Reference> element. 


"hash": The hash of all bytes that were identified by the corresponding <ds:Reference> element 
after applying all identified canonicalization and transformation algorithms. These are the 
same bytes that are hashed by the hash value in the <ds:DigestValue> element inside the 
<ds:Reference> element. 


A.3.4. XML Signer Certificate References 


The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The 
"type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash". 


* The "chain" type MUST be used when signature validation was performed using one or more 
certificates where some or all of the certificates in the chain are not present in the target 
signature. 


* The "chain hash" type MUST be used when signature validation was performed using one or 
more certificates where all of the certificates are present in the target signature. 


A.4. JOSE Header 
A.4.1. SVT Signing Key Reference 


The SVT JOSE header for XML signatures must contain one of the following header parameters in 
accordance with [RFC7515] for storing a reference to the public key used to verify the signature 
on the SVT: 


"x5c": Holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the 
public key that verifies the signature on the SVT MUST be the first certificate in the chain. 


"kid": A key identifier holding the Base64-encoded hash value of the certificate that can verify 
the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when 
signing the SVT as specified by the "alg" Header Parameter. 


Appendix B. PDF Signature Profile 


This appendix defines a profile for implementing SVTs with a signed PDF document, and it 
defines the following aspects of SVT usage: 


* How to include reference data related to PDF signatures and PDF documents in an SVT. 
* How to add an SVT token to a PDF document. 


PDF document signatures are added as incremental updates to the signed PDF document and 
signs all data of the PDF document up until the current signature. When more than one signature 
is added to a PDF document the previous signature is signed by the next signature and can not be 
updated with additional data after this event. 
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To minimize the impact on PDF documents with multiple signatures and to stay backwards 
compatible with PDF software that does not understand SVTs, PDF documents add one SVT token 
for all signatures of the PDF as an extension to a document timestamp added to the signed PDF as 
an incremental update. This SVT covers all signatures of the signed PDF. 

B.1. SVTs in PDF Documents 


The SVT for a signed PDF document MAY provide signature validation information about any of 
the present signatures in the PDF. The SVT MUST contain a separate "sig" claim (Signature object) 
for each signature on the PDF that is covered by the SVT. 


An SVT added to a signed PDF document MUST be added to a document timestamp in accordance 
with ISO 32000-2:2020 [ISOPDF2]. 


The document timestamp contains an [RFC3161] timestamp token (TSTInfo) in 
EncapsulatedContentInfo of the CMS signature. The SVT MUST be added to the timestamp token 
(TSTInfo) as an Extension object as defined in Appendix B.1.1. 


B.1.1. SVT Extension to Timestamp Tokens 


The SVT extension is an Extension suitable to be included in TSTInfo as defined by [RFC3161]. 
The SVT extension is identified by the Object Identifier (OID) 1.2.752.201.5.2. 


This extension data (OCTET STRING) holds the bytes of SVT JWT, represented as a UTF-8-encoded 
string. 


This extension MUST NOT be marked critical. 


Note: Extensions in timestamp tokens according to [RFC3161] are imported from the definition of 
the X.509 certificate extensions defined in [RFC5280]. 
B.2. PDF Signature SVT Claims 


B.2.1. PDF Profile Identifier 


When this profile is used, the SigValidation object MUST contain a "profile" claim with the value 
"PDF". 


B.2.2. PDF Signature Reference Data 


The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following 
elements: 


"id": Absent or a Null value. 
"sig_hash": The hash over the signature value bytes. 


"sb_hash": The hash over the DER-encoded SignedAttributes in SignerInfo. 
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B.2.3. PDF Signed Data Reference Data 


The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) 
with the following elements: 


"ref": The string representation of the ByteRange value of the PDF signature dictionary of the 
target signature. This is a sequence of integers separated by space where each integer pair 
specifies the start index and length of a byte range. 


"hash": The hash of all bytes identified by the ByteRange value. This is the concatenation of all 
byte ranges identified by the ByteRange value. 


B.2.4. PDF Signer Certificate References 


The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The 
"type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash". 


* The "chain" type MUST be used when signature validation was performed using one or more 
certificates where some or all of the certificates in the chain are not present in the target 
signature. 

* The "chain hash" type MUST be used when signature validation was performed using one or 
more certificates where all of the certificates are present in the target signature. 


Note: The referenced signer certificate MUST match any certificates referenced using ESSCertID 
or ESSCertIDv2 from [RFC5035]. 


B.3. JOSE Header 
B.3.1. SVT Signing Key Reference 


The SVT JOSE header must contain one of the following header parameters in accordance with 
[RFC7515] for storing a reference to the public key used to verify the signature on the SVT: 


"x5c": Holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the 
public key that verifies the signature on the SVT MUST be the first certificate in the chain. 


"kid": A key identifier holding the Base64-encoded hash value of the certificate that can verify 
the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when 
signing the SVT as specified by the "alg" Header Parameter. The referenced certificate 
SHOULD be the same certificate that was used to sign the document timestamp that contains 
the SVT. 
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Appendix C. JWS Profile 


This appendix defines a profile for implementing SVTs with a JWS signed payload according to 
[RFC7515], and it defines the following aspects of SVT usage: 


* How to include reference data related to JWS signatures in an SVT. 
* How to add an SVT token to JWS signatures. 


A JWS may have one or more signatures, depending on its serialization format, signing the same 
payload data. A JWS either contains the data to be signed (enveloping) or may sign any externally 
associated payload data (detached). 


To provide a generic solution for JWS, an SVT is added to each present signature as a JWS 
Unprotected Header. If a JWS includes multiple signatures, then each signature includes its own 
SVT. 


C.1. SVT in JWS 


An SVT token MAY be added to any signature of a JWS to support validation of that signature. If 
more than one signature is present, then each present SVT MUST provide information exclusively 
related to one associated signature and MUST NOT include information about any other signature 
in the JWS. 


Each SVT is stored in its associated signature's "svt" header as defined in Appendix C.1.1. 


C.1.1. "svt" Header Parameter 


The "svt" (Signature Validation Token) Header Parameter is used to contain an array of SVT 
tokens to support validation of the associated signature. Each SVT token in the array has the 
format of a JWT as defined in [RFC7519] and is stored using its natural string representation 
without further wrapping or encoding. 


The "svt" Header Parameter, when used, MUST be included as a JWS Unprotected Header. 


Note: A JWS Unprotected Header is not supported with JWS Compact Serialization. A 
consequence of adding an SVT token to a JWS is therefore that JWS JSON Serialization MUST be 
used either in the form of general JWS JSON Serialization (for one or more signatures) or in the 
form of flattened JWS JSON Serialization (optionally used when only one signature is present in 
the JWS). 


C.1.2. Multiple SVTs in a JWS Signature 


If a new SVT is stored in a signature that already contains a previously issued SVT, 
implementations can choose either to replace the existing SVT or to store the new SVT in addition 
to the existing SVT. 


If a JWS signature already contains an array of SVTs and a new SVT is to be added, then the new 
SVT MUST be added to the array of SVT tokens in the existing "svt" Header Parameter. 
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C.2. JWS Signature SVT Claims 


C.2.1. JWS Profile Identifier 


When this profile is used, the SigValidation object MUST contain a "profile" claim with the value 
"yws". 


C.2.2. JWS Signature Reference Data 


The SVT Signature object MUST contain a "sig ref" claim (SigReference object) with the following 
elements: 


"sig hash": The hash over the associated signature value (the bytes of the base64url-decoded 
signature parameter). 


"sb_hash": The hash over all bytes signed by the associated signature (the JWS Signing Input 
according to [RFC7515]). 


C.2.3. JWS Signed Data Reference Data 


The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) 
with the following elements: 


"ref": This parameter MUST hold one of the following three possible values: 


1. The explicit string value "payload" if the signed JWS Payload is embedded in a "payload" 
member of the JWS. 

2. The explicit string value "detached" if the JWS signs detached payload data without 
explicit reference. 

3. A URI that can be used to identify or fetch the detached Signed Data. The means to 
determine the URI for the detached Signed Data is outside the scope of this specification. 


"hash": The hash over the JWS Payload data bytes (not its base64url-encoded string 
representation). 


C.2.4. JWS Signer Certificate References 


The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The 
"type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash". 


* The "chain" type MUST be used when signature validation was performed using one or more 
certificates where some or all of the certificates in the chain are not present in the target 
signature. 

* The "chain hash" type MUST be used when signature validation was performed using one or 
more certificates where all of the certificates are present in the target signature JOSE header 
using the "x5c" Header Parameter. 
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C.3. SVT JOSE Header 
C.3.1. SVT Signing Key Reference 


The SVT JOSE header must contain one of the following header parameters in accordance with 
[RFC7515] for storing a reference to the public key used to verify the signature on the SVT: 


"x5c": Holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the 
public key that verifies the signature on the SVT MUST be the first certificate in the chain. 


"kid": A key identifier holding the Base64-encoded hash value of the certificate that can verify 
the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when 
signing the SVT as specified by the "alg" Header Parameter. 


Appendix D. Schemas 


D.1. Concise Data Definition Language (CDDL) 
The following informative CDDL [RFC8610] expresses the structure of an SVT token: 


svt - ( 
jti: text 
iss: text 
iat: uint 


? aud: text / [* text] 
? exp: uint 
sig val claims: SigValClaims 


} 


SigValClaims = { 
ver: text 
profile: text 
hash_algo: text 
sig: [+ Signature] 
? ext: Extension 


Signature = { 
sig_ref: SigReference 
sig_data_ref: [+ SignedDataReference] 
signer_cert_ref: CertReference 
sig_val: [+ PolicyValidation] 
? time_val: [* TimeValidation] 
? ext: Extension 


} 


SigReference = { 
? id: text / null 
sig_hash: binary-value 
sb_hash: binary-value 


} 
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SignedDataReference = { 
ref: text 
hash: binary-value 


} 


CertReference = { 
type: "chain" / 
ref: [+ text] 


"chain. hash" 


PolicyValidation - ( 
pol: text 
res: "PASSED" / "FAILED" / "INDETERMINATE" 
? msg: text / null 
? ext: Extension 


} 


TimeValidation = { 
"time": uint 
type: text 
iss: text 
? id: text / null 
? hash: binary-value / null 
? val: [* PolicyValidation] 
? ext: Extension 


Extension = { 
+ text => text 
) / null 


binary-value - text ; base64 classic with padding 


D.2. JSON Schema 


The following informative JSON schema describes the syntax of the SVT token payload. 


"$schema": "https://json-schema.org/draft/2020-12/schema" , 
"title": "Signature Validation Token JSON Schema", 
"description": "Schema defining the payload format for SVTs", 
"type": "object", 

"required": [ 


"sig. val. claims" 
"properties": { 
vI ER í 
"description": "JWT ID", 
"type" : "string" 
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"description": "Issuer", 

"type" 0 "string" 
ái 

"description": "Issued At", 

"type": "integer" 


m 
"aud": ( 


"description": "Audience", 


"items": type": "string"} 


"exp": { 


"description": "Expiration time (seconds since 


"type": "integer" 


"sig val claims": 1 


"description": "Signature validation claims", 


"type": "object", 

"required": [ 
"ver", 
"profile", 
"hash. algo", 
" sig" 


"properties": { 
"ver": ( 
"description": "Version", 
"type": "string" 


"profile": { 


"description": "Implementation profile", 


"type": "string" 


e 
"hash. algo": ( 


"description": "Hash algorithm URI", 


"type": "string" 


a 

sig": 
"description": "Validated signatures", 
"type": "array", 
"items": 

"Sref": "#/Sdef/Signature" 

"minItems": 1 

H 

"ext": 
"description": "Extension map", 
"Sref": "#/Sdef/Extension" 

} 


"additionalProperties": false 
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"additionalProperties": false, 
"Sdef": { 
"Signature" :{ 
"type": "object", 
"required": [ 
"sig ref", 
"sig data ref", 
"signer cert ref", 
"sig. val" 


"properties": { 


SST QM hues A 
"description": "Signature Reference", 
"Sref": "#/Sdef/SigReference" 

e 

"sig data ref": 
"description": "Signed data array", 
"type": "array", 
"items": 

"Sref" : "#/Sdef/SignedDataReference" 

"minItems": 1 

} 


signer cert ref': { 
"description": "Signer certificate reference", 
"Sref": "#/Sdef/CertReference" 


"sig val': { 
"description": "Signature validation results", 
"type": "array", 
"items": ( 
"Sref": "#/Sdef/PolicyValidation" 
"minItems": 1 


"time. val": { 


"description": "Time validations", 
"type": "array", 
"items": 


"Sref": "#/Sdef/TimeValidation" 


ai 

Ee 
"description": "Extension map", 
"Sref": "#/Sdef/Extension" 


"additionalProperties": false 


} 


igReference" :{ 
"type": "object", 
"required": [ 
"sig hash", 
"sb. hash" 


"properties": { 


"sig hash": í 
"description": "Hash of the signature value", 
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"type": “Strings, 
"format": "base64" 


e 

"sb hash": { 
"description": "Hash of the Signed Bytes", 
"type": "string', 
"format": "base64" 


m 

Tak í 
"description": "Signature ID reference", 
"type": ["string", "null" ] 


"additionalProperties": false 
je 
"SignedDataReference": { 

"type": "object", 

"required": [ 


] DU 
"properties": { 
Ire fies 
"description": "Reference to the signed data", 
"type": "string" 


e 

"hash": { 
"description": "Signed data hash", 
"type": "string", 
"format": "base64" 


} 


"additionalProperties": false 


} 


ertReference" : { 
"type": "object", 
"required": [ 
types, 
"ref" 


"properties": { 
type": { 


"string", 
enum": [ "chain", "chain_hash" ] 


I 
ure T 
"description": "Certificate reference data", 
"type": "array", 
"items": ( 
"type": "string', 
"format": "base64" 


"minlItems"': 1 


} 


"additionalProperties": false 


k 
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"PolicyValidation" : { 
"type": "object", 
"required": [ 

lee 
MEOS 


"properties": { 
spol“ í 
"description": "Policy identifier", 
"type" S "string" 


"res": { 
"description": "Signature validation result", 
"type": "string", 
"enum": ["PASSED", "FAILED", "INDETERMINATE" ] 


"msg": { 
"description": "Message", 
"type": ["string", "null" ] 


"ext": d 
"description": "Extension map", 
"S$ref": "#/Sdef/Extension" 

} 


"additionalProperties": false 
i 
"TimeValidation": (í 

"type": "object", 

"required": [ 


"properties": { 

time": { 
"description": "Verified time", 
"type": "integer" 


"type" 2 í 
"description": "Type of time validation proof", 
"type" g "string" 


"iss": { 
"description": "Issuer of the time proof", 
"type" d "string" 


nidi: { 
"description": "Time evidence identifier", 
"type": ["string", null"] 


"hash": { 
"description": "Hash of time evidence", 
"type": ["string", "null" ], 
"format": "base64" 


a 
mV cll wae 
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"description": "Validation result", 
"type": "array", 
"items": 


"Sref": "#/Sdef/PolicyValidation" 


"ext": { 
"description": "Extension map", 
"Sref": "#/Sdef/Extension" 
} 
"additionalProperties": false 
ie 
"Extension": { 
"description": "Extension map", 
"type": ["object", "null"], 
"required": [], 
“additionalProperties": (í 
"type": "string" 


Appendix E. Examples 


The following example illustrates a basic SVT according to this specification issued for a signed 
PDF document. 


Note: Line breaks in the decoded example are inserted for readability. Line breaks are not 
allowed in valid JSON data. 


Signature validation token JWT: 
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eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHNOZ rdnlqYUtWSmFWcU1G 
QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFskK2Z2cGF IMWo4aWJnNTJRQnkxUFE9 
PSIsInR5cCI6GIkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC91 
eGFtcGx1lLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHROCHM6XC9cL3N3ZWRlIbmNv 
bm51Y3Quc2VcL3ZhbG1kYXRvcilsImlhdCI6MTYwMzQ10DQyMSwianRpIjoiNGQx 
Mzk2Z jFmZ jcyOGY0MGQ1Mj QwM212MWM1NzQO0ODYiLCJzaWdfdmFsX2NsYWltcyI6 
eyJzaWciOlt7ImV4dCI6bnVsbCwic21nX3ZhbCI6W3sibXNnIjoiTO0siLCJleHQi 
Om51bGwsInJlcyI6IlBBUTNFRCIsInBvbCI6ImhOdHA6XC9cL21kLnN3ZWRlbmNv 
bm51Y3Quc2VcL3N2dFwvc21ndmFsLXBvbGl1jeVwvdHMtcGtpeFwvMDEifVO0sInNp 
Z19yZWYiOnsic21nX2hhc2gi0iJ5Y2VQVkxJemRjcEs5N01ZT2hGSWYxbnk30Uht 
SUNiU1Z6SWVaTmJpem83ckdJd@hOT j BOWE1LTeUtHakN2bm9uT2FRR2ZMXC9QM3ZE 
dET40H1LU1d1WGc9PSIsIm1kIjoiaWQtNzM50D1jNmZjMDYZNjM2YWI1ZTc1M2Yx 
MGY3NTcONjciLCJzY190o0YXNoIjoiQm9QVjRXQO0E5cOF JYWhqSzFIYWpmRnhpKO0F6 
QzZRKR1R1ZjM5VZNaV2p jekRDVVJA4ZGM5WWVOZUhOe Y3hHVmVnZ3BASEOo3NVwvY 1E3 
SEAxZERkbGI15SXdnPTOifSwic21nbmVyX2NlcnRfcmVmIjp7InJlZil6WyIxK2Fh 
SmVOZzdyZWxFUmxVRF1FaVUOWk1aaFQ0U1V2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4 
XCO9QTnREcnB1cVE2WGZya0g5d11ESzRleTBSNFdyTkVybnc9PSIsImgOUER4YjVa 
S214MWVUUS3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl10cUcwa2dla2Y2VzNv 
THprVHd3dXJJaDZZOUFhZ1pZcWMyelAycEUycDRRPTOiLCJEZDJDNXNCME 1PUWVN 
Vm5FQmtNNVESVzk2bUJITnd3YTJOelhNcytMd3VZY09VdlBrcnlHUjBhUEc4Tzlu 
SVAzbGJ3NktqUTFoRG1SazZ6QzhAMmpkZz09110sInR5cGUiOiJjaGFpbl9oYXNo 
InOsInNpZ19kYXRhX3Jl1Zil6W3sicmVmIjoiliwiaGFzaCI6IkZjR3BPT2YA4aWxj 
UHQyMUGEZDJ j R25MRORAU1M1a j dzdkG0 YXBwMkgOMWRERUXtMKN6Y2VUWTAybmR1 
SmZXamludG1RMzc2SWxYVE9Bc jMxeXpZenNnPTOifSx7InJlZil6IiNAYWRlcyOx 
MWEXNTVkKOTJiZjUINZCONJEZYmI3Y j Y2MTQ3N2NmZCIsImhhc2gi0iJLUmtnY1lo2 
UFwvbmhVNjNJTWswR21VZ1VcLORUd3Z1WW10ZVF rd@d1SnFDNUJ6VESWOGJRYnB1 
ZFRUdVdKUHhxdkowUlkANGh3bTdlWVwvZzBICkFPZWdLdz09In1dLCJ0aW11X3Zh 
bCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwi 
aGFzaF9hbGdvIjoiaHROcDpcL1wvd3d3LnczLm9yZ1wvM;j AwMVwvMDRcL3htbGVu 
YyNzaGET1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE. mJq6TG100PwnYSs. hyUbuX 
mrLJpuk8GR5YrndeOucPUYAwPxHt. f68JIQyFTiO0ag09VJjn1R7Pj3Jt6WGO9pYVN 
n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo.. 
31-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HFOSHgn3InpqBev3hm2SLw3hH5BCM 
rywBAhHYE6OGE0a0J6ktA5UP0 j IIHfaw9ilwIiJtHTaGuvtyWSLk5cshmun9Hkdk 
kRTA75bzuq0OIydOqh070rA8Gje-s4ATwAxzttgKx1KSkvy8n5FqvzWdsZvclCG2mY 
Y9rMxh. 7607NXcxa j APAyDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRMAC5A 
qxbDOBXPLyoMr4qn4ALRJCHxOeLZ603ugvDOOWsy jk3eliyBwDu8qJH7UmyicLxDc 
Cr@hUK_kvREqjD2Z 


Decoded JWT Header: 


"kid" :"OenI+434JhbvfDntfV\ /8r0xG7FkvyjakKVJaVqIFBXohVhAe5fK8anov 


1S688r7Kbal+fvpaH1 j 8ibg52QBy1PQ==", 


"typ" 2 WES. : 
"alg" :"RS512" 
} 
Decoded JWT Claims: 
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"aud" : "http://example.com/audience1", 
"iss" : "https://swedenconnect.se/validator", 
"iat" : 1603458421, 
"jti" : "4d1396f1ff728f40d52403b61c574486" , 
"sig val claims" : { 

Sig) ce 


neXt c null 

"res" : "PASSED", 

pol" : "http://id.swedenconnect.se/svt/sigval-policy/ 
ts-pkix/01" 

Ile 


"sig ref" : ( 
"sig hash" : "ycePVLIzdcpK971YOhFIfiny79HmICbSVzIeZNbizo7rGIw 
HNNOzXISyKGjCvnonOaQGfL /P3vDtB88yKSWeXg--" , 
"id" : "id-73989c6fc063636ab5e753f10f757467", 
"sb hash" : "BoPV4WCA9sATahjK1Haj fFxitAzC4JGTuf39W3ZWjczDCURx 
dc9YeteHtcxGVeggpxHJ75/cQ7HN1dDdliyIwg--" 


} 


igner_cert_ref" : 

"ref" : [ "1*aaJetg7relERIUDYEiUAZIZhTARUviIQZuK701GFKaTPQ6y-* 
kx/PNtDrpuqQ6Xf rkH9wYDK4ey@y4WrNErnw==" , 
"h4PDxb5ZKmx1eTSqvVvYG8g33s05JZwB+NgEHFU4gc9tqG@kgH 
kfeW3oLzkTwwurIh6Y9AafZYqc2zP2pE2p4Q--", 
"Dd2C5sBOIOQeMVnEBKM5Q9W96mBHNwwa2tzXMs-LwuYcOUvPkr 
yGR@aPG809nNIP31bw6KjQ1hDmRk6zC8x2jdg==" ], 

"type" : "chain hash" 


"sig data ref" : [ ( 

ref" 2 " ae 

"hash" : "FcGpOOf8ilcPt21GDd2cGnLGDXxRS5j7svM4app2H41dDELm2Czc 
eTY@2ndeJFWjintmQ37611XTOAr31yzYzsg==" 


{ 

"ref" : "#xades-11a155d92bf55774613bb7b661477cfd", 

"hash" : "KRkgbZ6P/nhU631MkOGiUfU/DTwveYiteQkwGeJqC5BzTNV8bQb 
pedTTuWJPxqvJORY84hwm7eY / geHrAOegKw--" 

jall, 


"time. val" : [ ] 
E 
"ext" : null, 
v.e oTt Du 
"profile" : "XML", 
"hash. algo" : "http://www.w3.0rg/2001/04/xmlenc£sha512" 
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